README was still describing M1, and one line was simply wrong: it said
`client/` renders mock data. The mock-data search interface never landed,
the client is still the skeleton and #9 wires it straight to GraphQL.

- Current milestone moved to M2
- New "Where the code is" table, implemented vs. planned
- Local setup for `server/` too: DATABASE_URL, migrate, optional seed
- Server commands in the command table
- Infrastructure names `crate-api.service` and what CI deploys
- M1 row now lists what M1 actually delivered, not mock data that did not
  land
- Sort modes corrected to four, checked against `AlbumSort` in the schema

AI usage log gets the eight erikhfj rows missing since 1 October: the
#10 identity contract, the #8 VM runbook and the git clone, the #13 facet
trade-off, the #43 source-map-js override, the #44 deploy gap, the
displayName correction, the #45 review fixes, and this pass.

The displayName row is the kind the log intro calls out as most
important: the tool drafted a claim that a person had to correct.

Per #48 each member documents their own usage, so only erikhfj rows were
added. robertky's row from #46 was out of date order at the end of the
table and is now with the rest of 9 October, and his relative order
within the day is unchanged.

Co-Authored-By: opencode <noreply@opencode.ai>

#46 merged while this was open, so two README claims were behind.

The "Implemented" list now names the schema that actually exists: tracks,
simulated users, reviews and crate items, with trigger-maintained full-text
search over titles at weight A and artist names at weight B. Checked
against set_album_search_vector() in migration 0001 rather than the PR
description.

Also warns that db:seed is a reset command, not a loader. It replaces the
catalog and, through foreign-key cascades, deletes the reviews and crate
items hanging off it. docs/VM-setup.md gained that warning from #46 and
the README was quietly understating it.

Not changed: "searchAlbums is the only query with a resolver" is still
true after #46, which was schema only and added no resolvers.

Co-Authored-By: opencode <noreply@opencode.ai>

#46 landed migration 0001 for tracks, simulated users, reviews and crate
items, and pointed out that this deploy never runs db:migrate. It was
right. A deploy that lands new migration files and does not apply them is
the same gap as #44 one layer down: the code is current, the schema is
not.

Migrate runs before the restart, so the new build is never pointed at an
old database. It runs on every deploy because db:migrate is idempotent
(verified on #46), not only when the migration list changes.

DATABASE_URL is exported from the same .env the systemd unit loads. The
server package scripts look for `server/.env` instead, which may not
exist in the deploy root, so it is passed explicitly rather than assuming
the two agree. Node's --env-file does not override a variable already in
the environment, so this wins even when server/.env is present. Verified
that a URL-encoded password survives the sed extraction and the handoff
to the child process byte for byte.

Also rebased onto main, which brings #46 along.

Co-Authored-By: opencode <noreply@opencode.ai>

Fold #46 into the README and add db:migrate to the #45 deploy, plus the
DATABASE_URL reconciliation that came out of it.

Co-Authored-By: opencode <noreply@opencode.ai>